In general, a communication protocol is a system of digital message formats and rules for exchanging messages between computer systems. For example, a protocol may include signaling, authentication, and error detection and correction capabilities, and may define the syntax, semantics, and synchronization of communication between computer systems.
One type of communication that is frequently exchanged between computer systems is a remote procedure call (RPC). Typically, a RPC is an inter-process communication that allows a computer program, such as a client application, running on one computer system to cause another computer program, such as a server application, subroutine, or procedure, to execute on a second remote computer system over a network. There are several types of communication protocols available that provide support for RPCs. For instance, Microsoft's® .NET environment provides .NET Remoting and .NET Windows Communication Framework (WCF) for communicating RPCs. However, the use of .NET Remoting is limited because the applications (e.g., server application and client application) running on the two computer systems must be .NET applications. In addition, .NET Remoting does not provide bi-directional communication using duplex sockets and requires the server application to establish a “callback” socket to the client application across a different port. Further, although .NET WCF provides full duplex communications, .NET WCF is still limited to consumption by .NET languages.
Another type of protocol available that provides support for RPCs is a fixed-length field protocol. This type of protocol has a fixed length for each field in the message exchanged between the two applications (e.g., server application and client application). Thus, a drawback of this type of protocol is the server and client applications must be in strict agreement on the length of each field and the number of fields in each message. Such requirements reduce the flexibility of this protocol because new fields cannot be easily added or existing fields modified by either the server or client application without first obtaining support by the other side. Further, because the message structure has a fixed number of fields with fixed positions and length, whether data is present for a particular field or not, the message still consumes the same number of bytes and cannot adjust to a smaller number of bytes (e.g., smaller size) when a particular field does not contain data. Likewise, similar limitations are found with respect to binary protocols.
Finally, another type of protocol available that provides support for RPC's is a character delimited protocol. This type of protocol allows for variable length fields that are separated by a predetermined character delimiter such as the TAB character. However, although this type of protocol does not have a concept of message length and a message exchanged between applications (e.g., server application and client application) can vary in size the server and client applications are typically required to read a message until a delimiter is hit to establish data for a particular field in the message and to establish the message's boundary. Thus, if the delimiters are not correctly placed in the message with respect to number and position, the server and/or client applications may become quite confused reading the message. In addition, similar to a fixed-length protocol, the server and client applications must be in strict agreement on the number and order of the fields found in the message. As a result, the flexibility found in this type of protocol is typically limited.
Thus, a need in the art exists for a more flexible communication protocol that may be used to exchange messages such as RPCs. More specifically, a need in the art exists for a communication protocol that supports the exchange of messages between applications that are not language specific and allows a variable payload for the message. It is with respect to these considerations and others that the disclosure herein is presented.